Replacing the whole map means any other AdditionalSecrets key on the container is silently dropped, even though the if only tested the wekahome-cacert key. Today the map only ever has that one key (as the comment in extra_volumes.go:29-30 notes), so this is latent rather than broken — but it will break quietly the moment a second key is added, and the reserved-names list already depends on that same "exactly one entry" assumption in a second place.

Safer to mutate just the one key:

	if container.Spec.AdditionalSecrets["wekahome-cacert"] != newClientSpec.WekaHomeCacertSecret {
		if container.Spec.AdditionalSecrets == nil {
			container.Spec.AdditionalSecrets = map[string]string{}
		}
		if newClientSpec.WekaHomeCacertSecret == "" {
			delete(container.Spec.AdditionalSecrets, "wekahome-cacert")
		} else {
			container.Spec.AdditionalSecrets["wekahome-cacert"] = newClientSpec.WekaHomeCacertSecret
		}
		changed = true
	}

Also: "wekahome-cacert" is now a bare literal in three places (here, clientAdditionalSecrets, factory/container_factory.go:96) plus a derived "wekahome-cacert-secret" in resources.ReservedVolumeNames. Worth a single exported const so the reserved-name entry can be derived from it rather than hand-copied.

Two things here.

1. Concatenating every file in the secret dir will inline a private key if the user points cacertSecret at a kubernetes.io/tls secret. That's a very natural mistake — a TLS secret is the obvious thing to reach for, and it has tls.crt + tls.key. The BEGIN CERTIFICATE check passes (thanks to tls.crt), so tls.key lands verbatim inside /opt/weka/k8s-runtime/vars/wh-cacert/cert.pem, which is then pointed at by weka_cloud_ca_cert_path. Worth filtering to certificate blocks, or at least skipping files containing a private key:

for f in /var/run/secrets/weka-operator/wekahome-cacert/*; do
    [ -f "$f" ] || continue
    grep -q "BEGIN CERTIFICATE" "$f" || continue
    grep -q "PRIVATE KEY" "$f" && continue
    cat "$f" >> /opt/weka/k8s-runtime/vars/wh-cacert/cert.pem
    echo "" >> /opt/weka/k8s-runtime/vars/wh-cacert/cert.pem
done

That also removes the need for the post-hoc content test, since a dir with no PEM certs produces no file at all.

2. chmod 400 happens only after the loop, so the file exists with the default umask (typically 0644) for the duration of the concatenation. Harmless for a public CA bundle, but combined with (1) it's a real window on a private key. Set the mode before writing:

: > /opt/weka/k8s-runtime/vars/wh-cacert/cert.pem
chmod 400 /opt/weka/k8s-runtime/vars/wh-cacert/cert.pem

(then drop the trailing chmod, keeping only the rm -rf on the no-certs path).

Nit on the comment: "the glob skips the ..data/..2025_* dotfiles" — true, but the reason is that shell globs don't match leading dots, not the date; the ..2025_* naming will read as stale in a year. # the glob skips the secret's ..data/..timestamp dotfiles is enough.

This section describes an API that doesn't exist, which will send readers looking for symbols they can't find.

1. ReservedMountPathPrefixes (line 89) and "Reserved exact paths" (line 100) — extra_volumes.go:38-50 has a single ReservedMountPaths slice, and IsReservedMountPath applies the same on-or-under rule to every entry. There is no prefixes/exact split. The distinction the code actually makes is that a file entry (/opt/weka_runtime.py) reserves only itself simply because nothing lives under it — not because it's matched differently.

2. "name suffixes" (line 61) — no suffix reservation exists. extra_volumes.go:29-32 explicitly rejects that approach in favour of reserving the one literal derived name, which line 84-88 then correctly explains. The two statements contradict each other.

3. Line 84 says wekahome-cacert-secret "comes from spec.additionalSecrets" — it's the WekaContainer's spec.additionalSecrets, which users don't set; the operator populates it from spec.wekaHome.cacertSecret. Worth saying so, since as written it reads like a user-facing field.

Suggest collapsing 89-100 into one "Reserved mount paths (ReservedMountPaths) — a mount cannot land on, or under, any of:" list with the full 13 entries, and dropping "name suffixes" from line 61.

"Used only by the operator's own CR reporter … No volume, no mount, no container filesystem is involved" is not correct, including for the code in this PR.

The Helm wekahome.cacertSecret lands in env.Config.WekaHome.CacertSecret, and that is:

• the last-resort fallback returned by GetWekaHomeClientCacertSecret (internal/pkg/domain/wekahome.go:86), which this PR wires into AdditionalSecrets → a secret volume + mount on every client pod;
• copied into WekaHomeConfig.CacertSecret by GetWekahomeConfig (wekahome.go:32-34), which container_factory.go:87-98 turns into additionalSecrets["wekahome-cacert"] → a secret volume + mount on every backend pod.

So it is a genuine cluster-wide/client-wide default that is mounted, not a reporter-only knob. Someone reading this table would set the Helm value expecting no pod impact and get every weka pod remounted (and rolled, once the pod-config-hash gap is fixed).

Also on line 85 (WekaClient row): the precedence chain is described as client → same-namespace cluster, but omits the third step. Per wekahome.go:79-87 it's actually:

1. wekaClient.spec.wekaHome.cacertSecret
2. target cluster's spec.wekaHome.cacertSecret, only if same namespace
3. Helm wekahome.cacertSecret (the operator-wide default)

Worth stating all three explicitly, since (3) is what a cross-namespace client silently falls back to after the warning event.

One more omission worth a sentence somewhere in this file: weka_runtime.py:3202-3210 deletes the staged wh-cacert directory when the concatenated file contains no BEGIN CERTIFICATE. That's a deliberate and good safety valve, but from the operator's point of view it's a silent fall back to the OS trust store — the pod starts fine and nothing surfaces the misconfigured Secret. Readers debugging "I set cacertSecret and nothing changed" need to know to check that file's existence.

The crossNamespaceSkipped return is only consumed in buildClientWekaContainer, which runs on container creation (client_reconciler_loop.go:485-495). NewUpdatableClientSpec — the path taken on every reconcile of an existing client — discards it with whCaCert, _ := … (line 1377). So the "you must set cacertSecret yourself" warning event never reaches the users most likely to need it: someone who adds spec.wekaHome.cacertSecret to an existing cross-namespace cluster and wonders why their clients didn't pick it up. Emitting it from the reconcile path (still throttled) would fix that.

Small cleanup in the same function: the final if re-derives what sameNamespace already told you. Since clusterSecret is only populated when sameNamespace, reaching line 84 with a non-empty cluster secret implies !sameNamespace:

	if clientSecret != "" {
		return clientSecret, false
	}
	if clusterSecret != "" {
		return clusterSecret, false
	}
	// Only reachable with !sameNamespace, since clusterSecret is populated only when same-namespace.
	if targetCluster != nil && targetCluster.Spec.WekaHome != nil && targetCluster.Spec.WekaHome.CacertSecret != "" {
		crossNamespaceSkipped = true
	}
	return env.Config.WekaHome.CacertSecret, crossNamespaceSkipped

Also worth noting for the test suite: wekahome_test.go:70-79 uses same-secret for both the client and the cluster value, so it can't distinguish "client wins" from "cluster wins" — it passes under either precedence. Use distinct values there.

The /tmp guard is exact-match only, so mountPath: /tmp/foo (or /tmp/) sails through and shadows part of the operator's own tmpdir emptyDir. Same on-or-under rule the Go side uses (IsReservedMountPath) would be more consistent:

      {{- range .Values.manager.extraVolumeMounts }}
      {{- if or (eq .mountPath "/tmp") (hasPrefix "/tmp/" .mountPath) }}{{ fail "manager.extraVolumeMounts: the mount path \"/tmp\" is reserved by the operator" }}{{ end }}
      {{- end }}

Also nothing here catches duplicate names or duplicate mount paths within the user's own lists — Kubernetes will reject the Deployment, but with a much less obvious message than the two fails above. Low priority given the failure is at least loud.

Clearing CA secret leaves path set

Medium Severity

Clearing spec.wekaHome.cacertSecret now rewrites AdditionalSecrets to an empty map so replacement pods no longer stage a PEM, while SetWekaHome only adds weka_cloud_ca_cert_path and never removes it. After a documented pod recreate, that path still replaces the OS trust store and Weka Home TLS fails cluster-wide.

 

^{Reviewed by Cursor Bugbot for commit afac063. Configure here.}